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ABSTRACT 



This report describes the system of virtual I/O support for 
the Stanford Emmy. A PDP 11/05 controls a pool of peripherals, 
and communicates with the Emmy processor through a pair of mail- 
boxes. By issuing appropriate requests practically any peri- 
pheral can be emulated. Performance for single byte requests 
exceed 1000 bytes/ sec. 
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1 Introduction 

The emulation or interpretation of input/output operations for 
current architectures is extremely difficult due to the ad hoc nature 
of their design. Many devices are timing dependent or have mainte- 
nance modes unknown to users (and in some cases undocumented). Since 
it was not our intention to provide a connector to which the image 
machine's I/O device could be connected; a system of simulated devices 
was developed to replace the real hardware. 

For this purpose the "match"[4] interface was designed to connect 
the (unique) Emmy processor bus[1-2] to the Unibus. The Unibus is the 
center of a system of devices that will provide virtual I/O support to 
the Emmy processor. The control for the I/O system is a PDP 11/05 
processor executing Bell Laboratories' Mini-Unix operation system[3 3. 
Mini-Unix is a scaled down version of Unix capable of running without 
memory management. A 67Mbyte disk drive, tape drive, and five asyn- 
chronous serial communication lines are connected to the Unibus. 

A virtual device is a linear space of bytes and allows three 
operations on it: read, write, and seek. For example, a teletype key- 
board is modeled as a read only device. Whereas a disk requires map- 
ping the drive, head, cylinder, and sector into a linear space and al- 
lows read, write, and seek operations. Virtual devices are mapped 
into the Mini-Unix system as files. The Mini-Unix file system makes 
no distinction between ordinary files (maintained by the system on 
disk) and special files that are the physical devices connected to 
Mini-Unix. This lack of distinction between files allows complete 



transparency of the actual device being accessed. Therefore a virtual 
disk could be "assigned" to an ordinary file, say /tmp/dsk1, and go 
through the normal file structure; or be "assigned" to a special file, 
say /dev/si3, which is one of the system scratch disks. 

The communication between the Emmy system and the Mini-Unix system 
is controlled through a pair of mailboxes. These mailboxes are loaded 
with requests and the receiving system is signaled that the mail is 
present. One mailbox is for Emmy to Unix requests and the other is 
for Unix to Emmy requests or acknowledgments. Executing on the Mini- 
Unix system is the v -access program which processes the incoming and 
outgoing mailbox requests. This program is divided into three main 
sections. The first, pmail , processes the incoming mail and generates 
appropriate outgoing mail. The second, pcontrol , handles the confi- 
guration and status of the active virtual devices, along with load and 
dump control of the Emmy system. The third section is a simple vac- 
cess debug facility for initial checkout of emulator I/O. 

2_ Mailbox protocols 

The mailboxes are 16 byte blocks located at the low part of the 
operating system in unused interrupt vector locations. The mailbox is 
divided into various fields each 2 bytes long. The structure of the 
mailbox (from C) is shown in figure 1. 

The Emmy to Unix mailbox is loaded by the Emmy processor and sig- 
nals the Mini-Unix system by setting the flag member to a non-zero 
value. The Emmy processor detects the receipt of the mail when the 



struct rabox 
{ 

int command; 
int device; 
int bufadr[2]; 
int count; 
int flag; 

int unassigned[2]; 
} EJTOJJMBOX, UJOJEMBOX; 

Figure 1: Mailbox structure 



mail processing procedure (pmail) clears the flag. 

The Unix to Emmy mailbox is loaded by "pmail", and the Emmy pro- 
cessor is signaled by an interrupt (vector = 50 hex). The pmail pro- 
cedure detects the receipt of the mail when the Emmy processor clears 
the flag member. The mailbox protocols are not symmetric because the 
Mini-Unix system does not allow fast enough latency between fielding 
an interrupt and signaling a user program (in this case the "pmail" 
procedure). Also there is no overlap of Mini-Unix system requests made 
by "pmail" and consequently a test loop gives the smallest latency. 

The following four procedures implement the above protocols for 
putmail and getmail operations in each system. 

1.) putmail for Emmy processor. 

putmail ( contents ); 
begin 
while E_T0_UMB0X.flag is not equal to do 

pause a short time; 
move contents to EJTOJJMBOX; 
EJTOJJMBOX. flag := 1; 
end; 



2.) putmail for Mini-Unix system. 

putmaiK contents ); 
begin 
while UJTOJSMBOX.flag is not equal to do 

pause a short time; 
move contents to U_TO_EMBOX; 
U_TO_EMBOX.flag := 1; 
send interrupt to Emmy; 
end; 



3.) getmail operation for Mini-Unix system 

/* procedure that examines the Emmy_toJJnix mailbox and returns a 1 
if the mailbox contains new mail along with that mail, and a if 
emoty . 
*/ 

getmail ( tmpbox ) 

begin 

if EJTOJJMBOX.flag is equal to then return ( ); 

/* mail exists */ 

move contents of EJTOJJMBOX to tmpbox; 

EJTOJJMBOX.flag := 0; 

return( 1 ); 

end; 



4.) getmail operation for Emmy processor. 

note: This procedure would be called directly by the interrupt. 

getmail () 
begin 

process the Unix to Emmy request; 
U_TOJSMBOX.flag := 0; 
end ; 

The EJTOJJMBOX is located at unibus addresses 110-126 (octal) and 
Emmy bus byte addresses F80048-F80056 (hex). The UJTOJEMB'OX is locat- 
ed at unibus addresses 250-266 (octal) and Emmy bus byte addresses 
F800A8-F 80036 (hex). 



3. Files and Virtual Devices 

V-access provides a very simple interface to the Emmy processor. 
I/O requirements are neatly packaged into mailbox messages and ack- 
nowledgments clearly signal the completion of the request. Since the 
transfers occur across a system bus, the error rates are negligible 
and no error detection system exists. Constructing a disk emulation 
is easily mapped into the V-access interface. Blocks are mapped 1 to 1 
into some counterpart file in Mini-Unix. For each emulated disk ac- 
tion a similar action is requested of V-access. For example a 5 block 
disk read is emulated by seeking first to the start of the transfer 
and requesting 5 blocks. This procedure becomes more difficult when 
more unusual features are required. To illustrate this consider the 
program, say of a 360, that reformats the sectoring information dynam- 
ically. The emulation of that function would require some scheme to 
include sector information for various tracks and necessitate multiple 
requests to determine the location of a given disk address. Another 
aspect of I/O devices that a simple read, write, and seek operations 
do not adequately handle is magnetic tape functions. Magtapes store 
implicit length information into each record. So searching for the 
10th record is not a simple seek to 10 times the record size. For 
these reasons and more (mostly efficiency), virtual devices are sup- 
ported in three different fashions. 

The first is the already mentioned block reads, write, and seeks. 
Second is variable record "tape" access. When a device is declared to 
be a tape device, variable length records can be read or written. 41- 



so tapemarks can be written and sensed for allowing easy emulation of 
simple tape drives. 

The layout of a file to be used as a tape device differs from the 
simple linear vector. Tape files are organized with a 4K byte record 
length list followed by the actual records. Positive non-zero entries 
indicate the size of the record. Zero entries signal tapemarks, while 
a negative entry marks the end of file. The length list approach was 
motivated by the need to minimize the number of system calls to Mini- 
Unix and speed the operation of spacing to the next taperaark. This al- 
lows only 2048 records per tape device. While this may seem small, it 
will exceed the Mini-Unix file size limit when the average record 
length is greater than 512 bytes. Figure 3.1 illustrates the data 
structure. 

The third device type was motivated mostly for efficiency. Char- 
acter devices expect byte (or word) at a time transfers. By antici- 
pating this behavior data can be prefetched and buffered. This does 
require certain restrictions. It is necessary to request either input 
or outputs Also seeking is not allowed. The obvious examples of dev- 
ices suited to this device class are paper tape readers and punches. 

One device that exists in its own class is the terminal keyboard. 
Unique to this device is the lack of a end of file. Also reads to the 
keyboard may never be fulfilled or may already have been fulfilled. 
The special treatment of the keyboard device is explained when 
relevant. 
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Note: This file would appear in Mini-Unix with a 4896 byte length. 
Figure 3.1: Internal data structure of tape files. 



4_ Mailbox Requests and the pmail procedure 

All virtual devices are assigned a 16 bit (high bit=0) device 
number identifying the device to the mail processing procedure, 
"pmail". This number is arbitrarily chosen by the emulator or inter- 
preter. A request is identified by the associated request number, 
which the "pmail" procedure uses to index a branch table. 

The Emmy processor can view the mailbox as a call to an asynchro- 
nous processor that will notify the initiator when completed. The 
"pmail" procedure processes the requests and generates an acknowledg- 



menb upon completion. The acknowledgment indicates possible errors or 
returns data. The first two fields of the mailbox always hold the re- 
quest number and a unique device number. Field 3 is double length and 
varies in function dependent on the request. Typically it contains 
either a 24 bit address or immediate data. It is desigated as the 
"bufadr" field. The fourth field, designated as the "count" field, 
likewise varies in function. It is mostly used to hold and return 
transfer counts. The last field is used to prevent overwriting previ- 
ous mail and is controlled by the previously discussed protocols. 
Designated the "flag" field, it always is set by one processor and 
cleared by the other, preventing any deadlock problems. 

There is an incompatibility between the addressing conventions of 
the Emmy system and the Unibus. In the Emmy system the left most byte 
of a word or halfword is designated "byte zero", whereas the Unibus 
designates the right byte "byte zero". The "pmail" procedure 
transfers data two .different ways. Block devices transfer data as 16 
bit quantities to/from main memory and 32 bit quantities to/from con- 
trol store. Figure 4.1 illustrates the mapping of the addresses 
between Unix, main memory and control store for the various combina- 
tions of address and byte counts. It is sometimes necessary for the 
user to swap bytes in order for data to appear correctly. Data for 
tape devices is swapped before transfer to the Emmy system and after 
transfer out of the Emmy system. Tape devices are further restricted 
by requiring that transfers begin on halfword boundries and request an 
even number of bytes. 
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Emmy Main Memory 
Case 4: Odd Address (1), Odd Count (7) 
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XX - byte is destroyed during read operation 



Figure 4.1: Example Unix/Emmy transfers to illustrate address 
mapping of data. 
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Virtual devices must be accessed consistantly. Tape devices may 
only be manipulated with the tape requests. Likewise character dev- 
ices may only be accessed via IMMEDIATE requests. 

ii'J. Emmy to Unix Requests 

Emmy to Unix requests initiate data transfers and file control for 
the virtual devices. The valid requests with the mailbox field argu- 
ments are shown in Table 1 . 



Name 



Number 



READ 







WRITE 




1 


SEEK 




2 


READ IMMEDIATE 


3 


WRITE IMMEDIATE 


4 


ABORT 




5 


RESET .ILL 


_DE VICES 


6 


MULL 




7-10 


TAPEREAD 




11 


TAPEWRITE 




12 


SPTM 




13 


WRTM 




14 


REWIND 




15 


REWRITE 




16 


EXIT 




17 



Bufadr field 

Emmybus byte address 

Emmybus byte address 

32 bit unsigned offset 

unused 
4 byte immediate data 

unused 

unused 

unused 
Emmybus byte address 
Emmybus byte address 

unused 

unused 

unused 

unused 

unused 



Count field 

byte count 
byte count 

bias 

byte count 

byte count 

unused 

unused 

unused 

byte count 

byte count 

direction 

unused 

unused 

unused 

unused 



Table 4.1: Emmy to Unix requests 



4.1.1 READ Request 



The READ request initiates a transfer of the number of bytes 
specified in the "count" field from the file indicated by the given 
device number. The transfer starts at the specified Emmybus byte ad- 
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dress. The "count" field must have the high bit cleared. This allows 
up to 32,766 bytes per request. The "pmail" procedure breaks the re- 
quest into multiple 8192 byte transfers. If the request size is 
greater than 3192 then the "count" and "address" fields must be even. 
Control store request are further restricted where "count" and "ad- 
dress" fields must be a multiple of 4. 

4.J..2 WRITE Request 

The WRITE request initiates a transfer of the number of bytes 
specified in the "count" field. The data, starting at the given Em- 
mybus byte address, is transferee! to the file indicted by the device 
number. The specified count must have the high bit cleared. The 
"pmail" procedure breaks the request into multiple 3192 byte 
transfers. If the request size is greater than 8192 then the "count" 
and "address" fields must be even. Control store request are further 
restricted where "count" and "address" fields must be a multiple of 4. 
The "write request" is acknowledged after all of the data has been 
transfered out of the Emmy system. This gives a reasonable amount of 
overlap, since the acknowledgment will precede the last system write 
to Mini-Unix . 

4 . r. 3. SEEK Request 

The SEEK request updates the current file pointer by the amount in 
the "bufadr" field. The bias located in the "count" field indicates 
the type of update desired. The "file pointer" is a pointer to the 
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location in the virtual device's linear space where the next transfer 
will take place. This pointer is updated after each transfer. The 
bias is interpreted as indicated by Table 2. 

Bias Meaning File pointer (fp) 

absolute fp := bufadr field 

negative negative offset fp := fp - bufadr field 
positive positive offset fp := fp + bufadr field 

Table 2: Bias Interpretation for the SEEK Request. 

The bias is interpreted a 16 bit two's complement quantity. The SEEK 
request explicitly moves the "file pointer" in a file. READ and WRITE 
requests update the "file pointer" implicitly by the size of the 
transfer. If the Mini-Unix file which was referenced does not allow 
seeks (e.g. the CRT) then an error message is printed on the user's 
terminal. 

i-1-1 READ IMMEDIATE Request 

The READ_IMMEDIATE request transfers 1 to 4 bytes of data in the 
request acknowledgment. This request is used for devices that require 
small transfers to avoid the overhead of buffering the data. If the 
Mini-Unix device specified is a "tty", then the request is recorded 
and only acknowledged when the data becomes available. Only requests 
of 1 byte at a time are allowed from the user's keyboard. If the dev- 
ice number is unassigned the request is ignored. An appropriate error 
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message is printed on the user's terminal. If an end of file is 
reached on the device, then the request is ignored. An error message 
indicating the device is written to the user's terminal. 

4.J_.5 WRITE IMMEDIATE Request 

The WRITE_IMMEDIATE request requests that the number of bytes 
(maximum of four) indicated by the "count" field be transfered from 
the "bufadr" field to the specified virtual device. As was true for 
the READJEMMEDIATE request this request is primarily used for small 
transfers to save buffering overhead and complexity. The ordering of 
the "bufadr" field is: 

Unibus loc. Emmybus loc . 
bufadr CO] byte 2 bytel 011 '4 X'F8004C 

bufadrCl] byte4 byte3 0116 X'F3004E' 

If the device number is unassigned the request is ignored, and an er- 
ror message is written to the user's terminal. 

4. K6 ABORT Request 

The ABORT request terminates all previous requests for the speci- 
fied virtual device. It only assures that, after the ABORT is ack- 
nowledged, further acknowledgments will be for requests made after the 
ABORT. Between the sending and the acknowledgment of the ABORT re- 
quest, previous requests could finish and be acknowledged. 
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1-1-1 R^SET ALL DEVICES Request 

The RES ET_ALLJDE VICES request is the only request that doesn't 
specify a particular device. Instead it clears all requests in pro- 
gress and guaranties their termination when the RE5ET_ALL_DEVICES is 
acknowledged. Tnis request is used mostly to emulate bus wide clears 
and reset instructions. 

1-1-1 TAPEREAD Request 

The TAPEREAD request initiates a transfer of the next record from 
the file indicated by the given device number. The transfer starts at 
the specified Emmybus byte address (must be on 2 byte boundry) . If 
the next record is smaller or equal to the specified "count" field, 
then that number of bytes is transferred. All byte counts must be 
even and have the high bit cleared. When the next record is larger, 
only the number of bytes specified will be transferred. The rest of 
the record is ignored. If a tapemark or end of tape is encountered no 
data is transferred. 

1-1-2 TAPEWRITE Request 

The TAPEWRITE request initiates a transfer of the specified number 
of bytes. The data, starting at the given Emmybus byte address, is 
transferred to the file indicated by the device number. All addresses 
and counts must be even. A. write operation creates a new "end of 
tape" at the end of the record whether data existed past the current 
record or not. 
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1-1-I2. 3P ™ Request 

The SPTM request positions the file pointer (see section 4.1.3) to 
the next tape mark. The direction is indicated by the "count" field. 
When the "count" field is a -1 , then the file pointer is spaced back- 
wards and positioned to read the first encountered tape mark (or pos- 
sibly the beginning of tape) . Any other value in the "count" field 
positions the file pointer foward in the file following the next tape 
mark. Notice that forward spacing positions after the tapemark and 
backward spacing before the tapemark. Forward spacing past the end of 
file is ignored and the file pointer is positioned after the last 
record. 

_4.J_.JJ_ WRTM Request 

The WRTM request writes a null length record which will subse- 
quently be interpreted as a tape mark. The "count" and "bufadr" 
fields are unused . 

_4.J_.J2 REWIND Request 

THe REWIND request positions the file pointer to the beginning of 
the tape. The "count" and "bufadr" fields are unused. This is 
equivalent but not interchangeable (file types are different) with an 
absolute SEEK request to zero. 
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1-1-li REWRITE Request 

The REWRITE request executes the PASCAL REWRITE function to reset 
the file pointer to zero and truncate the file to zero length. 

_4.J_._14_ EXIT Request 

The EXIT request deassigns all active devices and returns to the 
envoker of V-access (probably the SHELL). There is no acknowledgment 
for this request except for the possible DEVICE_NOT_READY requests due 
to deassignments. The "device" field is used to return a status byte 
to the envoker of Y-access. 

4_._2 Unix to Emmy Requests 

Unix to Emmy requests are typically acknowledgments to earlier re- 
quests, or control requests to the emulator. The valid requests with 
the mailbox field arguments are shown in Table 3. 

The processing of Emmy to Unix requests begins with verification 
of the virtual device number. If it is unassigned, an error message 
is written to the user's terminal. All acknowledgments return the 
originally used virtual device number to identify the source of the 
acknowledgment. 



Request Name 



Number 



3ufadr 



READ FINISH 


1 


unused 


WRITE FINISH 


1 


unused 


SEEK FINISH 


2 


unused 


READ IMMEDIATE FINISH 


3 


immediate data 


WRITE IMMEDIATE FINISH 


4 


unused 


ABORT FINISH 


5 


unused 


RESET 


6 


unused 


BREAK 


7 


unused 


DEVICE READY 


8 


unused 


RESET ALL FINISH 


9 


unused 


DEVICE NOT READY 


10 


unused 


TAPEREAD FINISH 


11 


unused 


TAPEWRITE FINISH 


12 


unused 


SPTM FINISH 


13 


unused 


WRTM FINISH 


14 


unused 


REWIND FINISH 


15 


unused 
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Count 

number of bytes read 

number of bytes written 

error flag 

number of bytes read 

number of bytes written 

error flag 

unused 

unused 

unused 

unused 

unused 

number of byes read 

number or bytes written 

error flag 

error flag 

error flag 



Table 3: Unix to Emmy Requests 



4.2.J[ READ FINISH Request 



The READ_FINISH request is generated by the "pmail" procedure to 
acknowledge the completion of a previous READ request. The "count" 
field indicates the actual number of bytes transferred. If the origi- 
nal request specified an unassigned virtual device number the "count" 
field is set to zero, indicating an error. The "count" field is also 
set to zero when reading a device initially assigned to be only ac- 
cessed with READ_IMMEDIATE requests ( discussed in section 4). In any 
event, a READ request is always acknowledged with a READ_FINISH. The 
"device" field will be unchanged. 



4.2.2 WRITE FINISH Reque st 

The WRITE_FINISH request is generated by the "pmail" procedure to 
acknowledge the completion of a previous WRITE request. The "count" 
field indicates the actual number of bytes transferred. If the origi- 
nal request specified an unassigned virtual device number the "count" 
field is set to zero, indicating an error. The "count" field is also 
set to zero when transferring to a device initially assigned to be 
only accessed with WRITE — IMMEDIATE requests ( discussed in section 4). 
In any event a WRITE request is always acknowledged with a 
WRITEJFINISH. The "device" field will be unchanged. 

4.2.3 SEEK FINISH Request 

The SEEK_FINISH request is generated by the "pmail" procedure to 
acknowledge the completion of a previous SEEK request. If the origi- 
nal request specified an unassigned, "character", or "tape" device 
(described in section 4) then the "count" field is set to zero, indi- 
cating an error. Otherwise the SEEK is assumed successful and the 
"count" field is set to 1 . If the location exceeds the bounds of the 
file, then this error is not reported and subsequent requests are 
unpredictable. 

4.2.4 READ IMMEDIATE FINISH Request 

The READ_IMMEDIATE_FINISH request both acknowledges the 
READ_IMMEDIATE request and includes the immediate data in the "bufadr" 
field. The format of the immediate data is the same as used in the 
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WRITEJEMMEDIATE request (section 4.1.5). For the device that is as- 
signed to the user's keyboard this request acts differently. In 
essence the keyboard always assumes a character is desired and "pmail" 
sends a READ_IMMEDIATE_FINISH request whenever anything is typed. So 
a READ_IMMEDIATE request has no effect when the device is assigned to 
the user's keyboard. This is done because the typical terminal used 
in computer systems (teletypes and CRTs ) will send a typed character 
whether or not is i>ras requested. 

1-2.5 WRITE IMMEDIATE FINISH Request 

The WRITE__IMMEDIATE_FINISH request acknowledges the 

WRITEJCMMEDIATE ' Emmy to Unix request. "pmail" assumes the write 
operation will be successful and immediately sends this acknowledgment 
once the device number is found to be valid. 

4.2.6 ABORT FINISH Request 

The ABORTJFINISH request acknowledges the receipt of the ABORT re- 
quest. Any other Emmy to Unix request in progress will be terminated 
for the specified device. If the specified device number was invalid 
the "count" field is set to zero to indicate the error, otherwise it 
is set to one. 

4.2.7 RESET and BREAK Requests 

There are two special requests which are initiated by the user. 
Their functions are not specified by the "pmail" procedure and are 
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left to the needs of the emulation. 

It is intended that they be used as machine level interrupts ei- 
ther at a console or system reset level. One typical emulation used 
the break request to switch to console mode and the reset to force 
reinitializing itself. 

The RESET and BREAK device numbers are included in the "device" 
field to allow device number parsing by the emulation or interpreta- 
tion. The RESET request is generated by typing the arbitrarily as- 
signed "reset" character on the user terminal. Likewise the "break" 
request is generated by typing the "break" character on the terminal. 
The "break" and "reset" devices are initially unassigned and set to 
zero. 

4.2.8 DEVICE READY and DEVICE NOT READY Requests 

The DEVICE_READY request is generated by the procedure that con- 
trols the assignment of virtual device numbers and the unix file 
names. When the device number is assigned to a unix file, the 
DEVICE_READY request is sent with the indicated device number to be 
used or discarded as the emulation sees fit. 

The DEVICE_NOT_READY request signals the disassociation of a dev- 
ice number and a unix file. For example, the nova emulation uses 
these two requests to set and clear the device ready bits of its vir- 
tual disk platters. 
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4.2.9 RESET ALL FINISH Request 

The RESETJILL_FINISH request acknowledges the receipt of the 
RE SET_ALL_DE VICES request. The "device" field is set to the "reset" 
device if one is assigned, otherwise the most recent value is used. 

!•£•!£ TAPEREAD FINISH Request 

This request signals the completion of a previous TAPEREAD re- 
quest. The "count" field indicates the actual number of bytes 
transferred. If the "count" field is zero, then a tape mark was en- 
countered. When a -1 is returned an end of file was sensed. The 
"device" field indicates which device is being acknowledged. Unas- 
signed device numbers and non-tape devices in the initial TAPEREAD re- 
quest will be acknowledged with a return in the "count" field of zero, 
and an error message is written on the user's terminal. 

4 .2 . U_ TAPEWRITE FINISH Request 

The TAPEWRITE_FINISH request signals the completion of a previous 
TAPE_WRITE request. The "count" field indicates the actual number of 
bytes transferred, "pmail" generally assumes the write operation will 
be successful once the device number has been validated. 

4 .2.J12 SPTM FINISH Request 

The SPTMJFINISH request acknowledges a previous SPTM request. The 
spacing is assumed successful once the device number is validated. 
The "count" field is set to +1 when valid and zero on any error. 
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1-1-11 WRTM FINISH Request 

The WRTM_FINISH request acknowledges a previous WRTM request. The 
request is assumed successful once the device number is validated. 
The "count" field is set to +1 when valid and zero on any error. 

1-2 .J! REWIND FINISH Request 

The REWIND_FINISH request acknowledges a previous REWIND request. 
The rewind is assumed successful once the device number is validated. 
The "count" field is set to +1 when valid and zero on any error. 

1-1-11 REWRITE FINISH Request 

THe REWRITE_FINISH request acknowledges the completion of a 

REWRITE request. Once the device number is verified the "count" field 

is set to one indicating success, otherwise an error is signalled by 
the "count" set to zero. 

5. Device assignment and the pcontrol procedure . 

The association of unix file names with the virtual device numbers 
is handled by the "pcontrol" procedure. This association is a strict 
one to one mapping. Typing the special sequence "control b?" to the 
"pmail" procedure enters "pcontrol", where "?" is any character other 
than a "control b" . The second character now becomes the first char- 
acter of the command. If this second character had been a "control 
b" , then "pmail" would interprete the two "control b" f s as a single 
"control b" and generate a READ_IMMEDIATEJFINISH request (if the KEY- 
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BOARD is assigned). 

The "pcontrol" procedure reads an entire line of text and executes 
the appropriate command handler. While "pcontrol" is executing no 
mail processing is done. All keywords used by "pcontrol" can be ab- 
breviated to the shortest distinguishable string. The optional argu- 
ments are parsed in the same manner allowing abbreviations. Numerical 
arguments are interpreted as decimal numbers, if preceded by a zero, 
they are interpreted as octal numbers. The following sections discuss 
in detail each command. 

5_.J_ Assign Command 

The "assign" command associates the named unix file to the given 
virtual device number. The Mini-Unix file can be either a ordinary or 
special file. The command syntax is: 

assign <device num> [to] {<file name> J RESET [BREAK i KEYBOARD! 
CRT [NONE] C [read! write] [tape] ! cread ! cwrite ] 

The square brackets indicate optional arguments. The {...} re- 
quires that one argument be chosen. If RESET or BREAK is used instead 
of a Mini-Unix file name the RESET or BREAK device will be assigned to 
the given number. 

The user's terminal is a somewhat unique device since it acts both 
as a display and keyboard device to the "pmail" procedure and as the 
controller for the virtual access system. So (rather than use the 
normal unix name /dev/tty?) two special names, KEYBOARD and CRT, are 
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reserved for the user terminal's keyboard and display screen respec- 
tively. Different virtual device numbers must be used for the KEY- 
BOARD and the CRT since the device number must uniquely define the 
Mini-Unix file it is assigned to. 

If the device was already assigned "pcontrol" prompts the user to 
ask if the device number should be reassigned. Reassignment causes 
the current assignment to be terminated and the new file name as- 
signed. If the first letter of the reply is "y" , then the number is 
reassigned, otherwise the command is ignored. When the "NONE" option 
is used the device number is deassigned. Any further mail requests to 
that number will result in an error. 

The file name can be qualified to indicate the type of access al- 
lowed. The qualifier "READ" and "WRITE" only permit read or write 
mail requests to the file respectively. This is only enforced at the 
Unix system level. This has the result that WRITE requests will be 
acknowledged without an error for devices assigned as "read" devices. 
It remains the responsibility of the user to recognize this problem. 
In order to reduce the number of costly system calls, a special qual- 
ifier "cread" or "cwrite" is used to notify the "pmail" procedure that 
this device will only be accessed via READ_IMHEDIATE or 
WRITE_IMMEDIATE mail requests, "pmail" will then use local buffers to 
speed the transfers. The default access is standard read or write ac- 
cess. Typically papertape readers and punches will be assigned with 
the "cread" and "cwrite" qualifiers. Whereas a disk uses the default 
access. 
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The last qualifier, "tape", signals that the file is to be a tape 
device. If it doesn't exist a null length tape file is created. 

Many errors are reported by the "assign" command. Usually the en- 
tire command is ignored with no side effects. One exception is that 
an already assigned device number could be deassigned even when the 
command line is in error. 

5_.,2 Reassign Command 

The "reassign" command is syntactically the same as the assign 
command. Functionally the "reassign" command expects the specified 
device number to already be assigned and associates the number with 
the given file name. If the device number is unassigned, then "pcon- 
trol" prompts the user if the device number should be newly assigned. 
A "y" as the first letter of the response assigns the device number 
otherwise the command is ignored . The command syntax is : 

reassign <device num> [to] {<file name> i RESET J BREAK! KEYBOARD! 
CRT [NONE} C [read [write] [tape] ! cread ! cwrite ] 

5^.3. ! Command 

The "!" command submits the text string that follows the "!" to 
the Mini-Unix shell program for execution. 
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5_.4_ Debug Command 

The "debug" command invoces a preliminary debug routine to assist 
the of emulator I/O systems. This procedure scans the input keyboard 
and Emmy to Unix mailbox just as the "pmail" procedure does. But when 
mail is received the contents of the mailbox are only displayed on the 
terminal and the Emmy to Unix flag is cleared. The display is self- 
explanatory and contains all of the mailbox values. 

When a key is struck, "debug" collects a line of data, in octal, 
to be sent as a Unix to Emmy request. The input syntax is: 
<request> <device> <highadr> <lowadr> <count> 

All five values must be typed, "debug" then reports the success or 
failure in trying to send the request. An unsuccessfull response is 
due to the Unix to Emmy mailbox flag still being set. This indicates 
the previous mail request was not read. 

"debug" mode is exited by typing a request with the request number 
set to octal 40. 

JL'JI. Break Command 

The "break" command changes the break character to the specified 
character. The space, newline, erase, and kill characters are illegal 
and ignored. The character "M" is special and signifies no character. 
If "N" is used the break function will be turned off. The syntax is: 

break [is] <break character iN0NE> 
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5_.6_ Reset Command 

The "reset" command changes the reset character to the specified 
character. The space, newline, erase, and kill characters are illegal 
and ignored. The character "N" is special and signifies no character. 
If "N" is used the reset function will be turned off. The syntax is: 

reset [is] <reset character |NONE> 

5_.1_ Status Command 

The "status" command displays all the currant information on the 
assigned device numbers. The device number is displayed in octal fol- 
lowed by the Mini-Unix file name it is assigned to. The next column 
indicates with a "t" if tracing is turned on. Following the trace 
flag is the character, mode, and tape indicator columns. A. character 
device is signalled by a "c". The mode by "r","w", or "*" to indicate 
read, write, or update mode respectively. The tape indicator is set 
to "t" when true. The last field is the current location (in octal) 
of the file pointer for the device. 

5_._8 ~b Command 

The "control b" command causes the "pcontrol" procedure to ter- 
minate and return to the "pmail" procedure. 
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5_.9_ Trace Command 

The "trace" command forces all WRITE and WRITE_IMMEDIATE commands 
to the specified device number to be additionally displayed on the 
user's terminal. The optional "OFF" argument disables a previous 
trace command. The syntax is: 

trace < device number> [OFF] 

The device number specified must have been previously assigned to a 
Mini-Unix file (excluding the CRT). 

5.10 Cd Command 

The "cd" command acts equivalent to the unix "chdir" command. The 
current directory is changed to the text string that follows, 
"/etc/glob" is not used to interpret special characters, consequently 
the name must be spelled out exactly. The syntax is: 

cd <directory name> 

5.11 Kick Command 

The "kick" command forces a one byte READ__IMMEDIATE Emmy to Unix 
command to be processed for the specified device number. This is most 
useful to restart a device, after a reassignment, when the emulator's 
"device start" came prior to the reassignment. The syntax is: 

kick <device number > 
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5. 12 Clear Command 

The "clear" command clears the two mailbox flags. This is used to 
reset a hung mailbox. 

5. 13 Commands Command 

The "commands" command redirects the input of command lines to the 
specified file name. The commands are echoed on the display and exe- 
cuted until an end of file is reached. Control then returns to the 
user's terminal. The syntax is: 

commands [from] <file name> 

5 . 14 : Command 

The ":" command is a comment and causes no action. The text that 
appears after the ":" is ignored. 

5.15 Stty Command 

In order to understand the implications of the possible settings 
of the user tty it is necessary for the reader to study in the Unix 
manual the sections STTY(I) and STTY(II). Initially the "pmail" pro- 
cedure sets the terminal modes to: 

raw, anyp, -tabs, nlO, tabO, crO, nl, -echo, -lease. 

This will very closely send characters and print characters as typed. 
The expansion of tabs is the single exception. 
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When "pcontrol" is entered, the terminal modes are restored to 
the values saved during initialization. The user may change and 
display the current modes used by "pmail" with the "stty" command. 
The syntax is the same as used by the Unix "stty" command. The ef- 
fects for most settings are straight forward. "cooked" mode is a 
noteable exception. When a character is typed in cooked mode, vaccess 
requests an entire line from the Mini-Unix system. After the line is 
typed (with possible erase and kill processing), "pmail" processes the 
characters by either sending a burst of READ_TMMEDIATE_FINISH requests 
to the Emmy system; or ignores them if the KEYBOARD was unassigned. 
From the time the first character is typed untill the newline, vaccess 
does not process any incoming mail. Once the line has been disposed 
of, and before another character is typed, regular processing contin- 
ues. 

Using the KEYBOARD for block reads has some unpleasant side ef- 
fects. Once the "pmail" procedure receives the READ request all "con- 
trol b" processing is suspended. After the request was handled (and 
perhaps only partially so) "pmail" may pick up more characters that 
precede another READ request and throw them away or generate 
READ_IMMEDIATES that will be unexpected. All in all the terminal KEY- 
BOARD should use the READJCMMEDIATE requests to maintain data and pro- 
gram integrety. Of course the CRT is not effected by the above dis- 
cussion and is equally enamored to WRITE or WRITE_IMMEDIATE requests 
for any setting of the terminal modes. 
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5. 16 Exit Command 

The "exit" command closes all files and terminates the vaccess 
program. The program interrupt (rubout character) will prompt the 
user if vaccess should exit. A yes response will exit in the same 
manner as the "exit" command. 

6_ Performance 

The performance of an emulated I/O device is a function of many 
different factors, the most important of which is the "blocksize". 
Mailbox requests require a fixed amount of time to initially parse the 
request type and device assignment. Once a device is identified the 
transfer is started. The transfer time between the operating system 
and the Vaccess program is directly proportional to the blocksize. 
So, for small blocksizes the initial overhead dominates the total in- 
teraction time, while for the larger blocksizes the transfer rate is 
constant. Because of the buffering scheme used by the UNIX operating 
system, blocksizes above 512 bytes result in near constant transfer 
rates. There is one notable exception which involves the use of the 
"raw" device interface. Raw devices bypass the normal buffer mechan- 
ism and use direct disk transfers to the Vaccess program. For raw 
devices, the transfer rate is proportional to the blocksize. This 
provides much higher throughput when the blocksize exceeds 1024 bytes. 

UNIX makes no distinction, logically, between the physical dev- 
ices connected to it and its file system, but the transfer rates can 
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vary dramatically. Ordinary files are organized into a file system 
and are maintained by the operating system. Ordinary files are the 
easiest to manipulate but are limited to about one megabyte in size 
(this is a Mini-UNIX restriction). Special files are the actual dev- 
ices available on the system. Our current system divides the disk 
into two 16 megabyte scratch regions and two system regions used for 
swapping and the file system. Raw special files are special files 
that bypass the UNIX buffering scheme. They are restricted to com- 
plete block transfers (multiple of 512), but are ideal for disk emula- 
tions because of the considerable speed advantage. 

Figure 6.1 shows the expected transfer rates for the various file 
types and device structures. Tape devices refer to ordinary assigned 
with the "tape" qualifier. The curve labelled "character" refers to 
the expected transfer rates of ordinary files assigned with the 
"cread" or "cwrite" qualifier. The ordinary, special, and raw special 
labelled curves refer to the rates when assigned as block devices. 
The curves were generated using blocksizes that are powers of two and 
the actual curve between these points may be lower because of the 
internal blocking used by the UNIX file system. Data for blocksizes 
corresponding to card images and print images (80 and 132 bytes 
respectively) fit very closely to the curve. 
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Request 



Mailbox Fields 



Name 



Number 



Device 



Bufadr 



Count 



Pmail action 



READ 

WRITE 

SEEK 



READ_IMMEDIATE 

WRITE_IMMEDIATE 
ABORT 

RESET ALL DEVICES 



Device number 
Device number 
Device number 



Device number 

Device number 
Device number 

unused 



Address 

Address 

32 bit offset 



unused 



Byte count 
Byte count 
bias 

=0, absolute 
>0, positive 
<0, negative 
Byte count 



Immediate data Byte count 
unused unused 



unused 



unused 



NULL 


7-10 


unused 


unused 


unused 


TAPEREAD 


11 


Device number 


Address 


Byte count 


TAPEWRITE 


12 


Device number 


Address 


Byte count 


SPTM 


13 


Device number 


unused 


Direction 

= -1 , Backward 

i -1 , Forward 


WRTM 


14 


Device number 


unused 


unused 


REWIND 


15 


Device number 


unused 


unused 


REWRITE 


16 


Device number 


unused 


unused 


EXIT 


17 


Return Code 


unused 


unused 



'count' bytes 
'count' bytes 



Transfer 

Transfer 

Move file pointer 

by bias 



Request data in 

acknowledgment 

Transfer 'count' bytes 

Terminate all active 

requests 

Terminate all active 

requests for all devices 

Transfer "count" bytes 
Transfer "count" bytes 
Space to indicated 
Tapemark 

Write a tapemark 
Position at BOT 
Position at start of 
file and truncate to 
zero length 

Terminate the V-access 
program 
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Appendix C: Unix to Emmy Request Summary 



Request 



Mailbox Fields 



Name 



Number 



Device 



Bufadr 



Count 



Pmail action 



READ FINISH 





Device 


number 


unused 


Actual count 


READ 


WRITE FINISH 


1 


Device 


number 


unused 


Actual count 


WRITE 


SEEK FINISH 


2 


Device 


number 


unused 


Error flag * 


SEEK 


READ_IMMEDIATE_FINISH 


3 


Device 


number 


Immediate data 


Actual count 


READ_IMMEDIATE or 
typed character 


WRITE IMMEDIATE FINISH 


4 


Device 


number 


unused 


Original count 


WRITE IMMEDIATE 


ABORT FINISH 


5 


Device 


number 


unused 


Error flag * 


ABORT 


RESET 


6 


Reset 


d ev ic e 


unused 


unused 


'reset' character 
typed on keyboard 


BREAK 


7 


Break 


device 


unused 


unused 


'Break* character 
typed on keyboard 


DEVICE_READY 


8 


Device 


number 


unused 


unused 


assignment by 


, 












'pcontrol' 


RESET ALL FINISH 


9 


Break 


device 


unused 


unused 


RESET_ALL_DE VICES 


DEVICE_NOT_READY 


10 


Device 


number 


unused 


unused 


deassignment by 
'pcontrol' 


TAPEREAD FINISH 


11 


Device 


number 


unused 


Actual count 


TAPEREAD 


TAPEWRITE FINISH 


12 


Device 


number 


unused 


Actual count 


TAPEWRITE 


SPTM FINISH 


13 


Device 


number 


unused 


Error flag * 


SPTM 


WRTM FINISH 


14 


Device 


number 


unused 


Error flag * 


WRTM 


REWIND FINISH 


15 


Device 


number 


unused 


Error flag * 


REWIND 


REWRITE FINISH 


16 


Device 


number 


unused 


Error flag »' 

* =1 , success 
=0, error 


REWRITE 
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Appendix D: Pcontrol Command Syntax Summary 

assign <device num> [to] {<file name> ! RESET [BREAK i KEYBOARD! 

CRT [NONE} C [read! write] [tape] ! oread i owrite ] 

break [is] <break character ! NOME> 

cd <directory name> 

clear 

commands [from] <file name> 

debug 

exit 

kick < device number > 

reassign < device num> [to] {<file name> i RESET 'BREAK, 'KEYBOARD! 

CRT [NONE} C [read [write] [tape] ! cread ! cwrite ] 

reset [is] <reset character !NONE> 

status 

stty arg1,... 

trace <device number> [OFF] 

!< shell command> 

~b 

: <command comment> 
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